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Abstract 


This document describes an architecture for describing SNMP 
Management Frameworks. The architecture is designed to be modular to 
allow the evolution of the SNMP protocol standards over time. The 
major portions of the architecture are an SNMP engine containing a 
Message Processing Subsystem, a Security Subsystem and an Access 
Control Subsystem, and possibly multiple SNMP applications which 
provide specific functional processing of management data. 
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1. Introduction 
1.1. Overview 


This document defines a vocabulary for describing SNMP Management 
Frameworks, and an architecture for describing the major portions of 
SNMP Management Frameworks. 


This document does not provide a general introduction to SNMP. Other 
documents and books can provide a much better introduction to SNMP. 
Nor does this document provide a history of SNMP. That also can be 
found in books and other documents. 


Section 1 describes the purpose, goals, and design decisions of this 
architecture. 


Section 2 describes various types of documents which define (elements 
of) SNMP Frameworks, and how they fit into this architecture. It also 
provides a minimal road map to the documents which have previously 
defined SNMP frameworks. 


Section 3 details the vocabulary of this architecture and its pieces. 
This section is important for understanding the remaining sections, 
and for understanding documents which are written to fit within this 
architecture. 


Section 4 describes the primitives used for the abstract service 
interfaces between the various subsystems, models and applications 
within this architecture. 


Section 5 defines a collection of managed objects used to instrument 
SNMP entities within this architecture. 


Sections 6, 7, 8, 9, 10 and 11 are administrative in nature. 


Appendix A contains guidelines for designers of Models which are 
expected to fit within this architecture. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.2. SNMP 
An SNMP management system contains: 


- several (potentially many) nodes, each with an SNMP entity 
containing command responder and notification originator 
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applications, which have access to management instrumentation 
(traditionally called agents); 


- at least one SNMP entity containing command generator and/or 
notification receiver applications (traditionally called a 
manager) and, 


- a management protocol, used to convey management information 
between the SNMP entities. 


SNMP entities executing command generator and notification receiver 
applications monitor and control managed elements. Managed elements 
are devices such as hosts, routers, terminal servers, etc., which are 
monitored and controlled via access to their management information. 


It is the purpose of this document to define an architecture which 
can evolve to realize effective management in a variety of 
configurations and environments. The architecture has been designed 
to meet the needs of implementations of: 


—- minimal SNMP entities with command responder and/or 
notification originator applications (traditionally called SNMP 
agents), 


- SNMP entities with proxy forwarder applications (traditionally 
called SNMP proxy agents), 


- command line driven SNMP entities with command generator and/or 
notification receiver applications (traditionally called SNMP 
command line managers), 


- SNMP entities with command generator and/or notification 
receiver, plus command responder and/or notification originator 
applications (traditionally called SNMP mid-level managers or 
dual-role entities), 


- SNMP entities with command generator and/or notification 
receiver and possibly other types of applications for managing 
a potentially very large number of managed nodes (traditionally 
called (network) management stations). 
1.3. Goals of this Architecture 
This architecture was driven by the following goals: 
- Use existing materials as much as possible. It is heavily based 


on previous work, informally known as SNMPv2u and SNMPv2*, 
based in turn on SNMPv2p. 
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- Address the need for secure SET support, which is considered 
the most important deficiency in SNMPv1 and SNMPv2c. 
- Make it possible to move portions of the architecture forward 
in the standards track, even if consensus has not been reached 


on all pieces. 


- Define an architecture that allows for longevity of the SNMP 
Frameworks that have been and will be defined. 


- Keep SNMP as simple as possible. 


- Make it relatively inexpensive to deploy a minimal conforming 
implementation. 


- Make it possible to upgrade portions of SNMP as new approaches 
become available, without disrupting an entire SNMP framework. 


- Make it possible to support features required in large 
networks, but make the expense of supporting a feature directly 
related to the support of the feature. 


1.4. Security Requirements of this Architecture 


Several of the classical threats to network protocols are applicable 
to the management problem and therefore would be applicable to any 
Security Model used in an SNMP Management Framework. Other threats 
are not applicable to the management problem. This section discusses 
principal threats, secondary threats, and threats which are of lesser 
importance. 


The principal threats against which any Security Model used within 
this architecture SHOULD provide protection are: 


Modification of Information 
The modification threat is the danger that some unauthorized 
entity may alter in-transit SNMP messages generated on behalf 
of an authorized principal in such a way as to effect 
unauthorized management operations, including falsifying the 
value of an object. 


Masquerade 
The masquerade threat is the danger that management operations 
not authorized for some principal may be attempted by assuming 
the identity of another principal that has the appropriate 
authorizations. 
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Secondary threats against which any Security Model used within this 
architecture SHOULD provide protection are: 


Message Stream Modification 
The SNMP protocol is typically based upon a connectionless 
transport service which may operate over any subnetwork 


service. The re-ordering, delay or replay of messages can and 
does occur through the natural operation of many such 
subnetwork services. The message stream modification threat is 


the danger that messages may be maliciously re-ordered, delayed 
or replayed to an extent which is greater than can occur 
through the natural operation of a subnetwork service, in order 
to effect unauthorized management operations. 


Disclosure 
The disclosure threat is the danger of eavesdropping on the 
exchanges between SNMP engines. Protecting against this threat 


may be required as a matter of local policy. 


There are at least two threats against which a Security Model within 
this architecture need not protect, since they are deemed to be of 
lesser importance in this context: 


Denial of Service 
A Security Model need not attempt to address the broad range of 
attacks by which service on behalf of authorized users is 
denied. Indeed, such denial-of-service attacks are in many 
cases indistinguishable from the type of network failures with 
which any viable management protocol must cope as a matter of 
course. 


Traffic Analysis 
A Security Model need not attempt to address traffic analysis 
attacks. Many traffic patterns are predictable - entities may 
be managed on a regular basis by a relatively small number of 
management stations - and therefore there is no significant 
advantage afforded by protecting against traffic analysis. 


1.5. Design Decisions 


Various design decisions were made in support of the goals of the 
architecture and the security requirements: 


- Architecture 
An architecture should be defined which identifies the 
conceptual boundaries between the documents. Subsystems should 
be defined which describe the abstract services provided by 
specific portions of an SNMP framework. Abstract service 
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interfaces, as described by service primitives, define the 
abstract boundaries between documents, and the abstract 
services that are provided by the conceptual subsystems of an 
SNMP framework. 


- Self-contained Documents 
Elements of procedure plus the MIB objects which are needed for 
processing for a specific portion of an SNMP framework should 
be defined in the same document, and as much as possible, 
should not be referenced in other documents. This allows pieces 
to be designed and documented as independent and self-contained 
parts, which is consistent with the general SNMP MIB module 
approach. As portions of SNMP change over time, the documents 
describing other portions of SNMP are not directly impacted. 
This modularity allows, for example, Security Models, 
authentication and privacy mechanisms, and message formats to 
be upgraded and supplemented as the need arises. The self- 
contained documents can move along the standards track on 
different time-lines. 


This modularity of specification is not meant to be interpreted as 
imposing any specific requirements on implementation. 


- Threats 
The Security Models in the Security Subsystem SHOULD protect 
against the principal and secondary threats: modification of 
information, masquerade, message stream modification and 
disclosure. They do not need to protect against denial of 
service and traffic analysis. 


- Remote Configuration 
The Security and Access Control Subsystems add a whole new set 
of SNMP configuration parameters. The Security Subsystem also 
requires frequent changes of secrets at the various SNMP 
entities. To make this deployable in a large operational 
environment, these SNMP parameters must be remotely 
configurable. 


- Controlled Complexity 
It is recognized that producers of simple managed devices want 
to keep the resources used by SNMP to a minimum. At the same 
time, there is a need for more complex configurations which can 
spend more resources for SNMP and thus provide more 
functionality. The design tries to keep the competing 
requirements of these two environments in balance and allows 
the more complex environments to logically extend the simple 
environment. 
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2. Documentation Overview 


The following figure shows the set of documents that fit within the 
SNMP Architecture. 


PERSSS SSS 522 S Document- Set =3=39323=352=+=93===22+59=225225=5 Í 
| +---------—- + +----------------- + +---------------- + | 
| | Document | | Applicability * | | Coexistence | 
| | Roadmap | | Statement | | & Transition | 
+---------- + Ho + +---------------- + 
| | 
| +--------------------------------------------------------------- + | 
| | Message Handling | | 
| +---------------- + +----------------- + +----------------- + | | 
| | | Transport | | Message | | Security | 
| | Mappings Processing and | 
Dispatcher 
| | +---------------- + +----------------- + +----------------- + | | 
| +--------------------------------------------------------------- + | 
| 
| HO + | 
| PDU Handling | 
+---------------- + +----------------- + +----------------- + 
| | | Protocol | | Applications | Access | 
| | | Operations | | Control | 
| | +---------------- + +----------------- + +----------------- + | | 
| +--------------------------------------------------------------- + | 
ee 7 
| | Information Model hl 
| | +-------------- +  +-------------- + +--------------- + | | 
| | | Structure of | | Textual | | Conformance | | 
| | | Management | | Conventions | | Statements | | 
| | Information | | | | | | 
4+-------------- Ho  +-------------- + 4+--------------- + 
| $o--- 5-777-757-5555 5-5-5 5-5-5 5 + | 
| 
| +--------------------------------------------------------------- + | 
| | MIB Modules written in various formats, e.g.: | 
4+------------- + $------------- + $---------- + +---------- + 
| | | Standard v1 | | Standard v1 | | Historic | Draft v2 | | | 
| | | REC 1157 | | RFC 1212 | | RFC 14xx | | RFC 19xx | | | 
| | | format | | format | | format | | format | | 
| | +------------- + +------------- + +---------- + +---------- + t 
| +--------------------------------------------------------------- + | 
| | 
4+------------------------------------------ === === === == === === === + 
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Those marked with an asterisk (*) are expected to be written in the 
future. Each of these documents may be replaced or supplemented. 
This Architecture document specifically describes how new documents 
fit into the set of documents in the area of Message and PDU 
handling. 


2.1. Document Roadmap 


One or more documents may be written to describe how sets of 
documents taken together form specific Frameworks. The configuration 
of document sets might change over time, so the "road map" should be 
maintained in a document separate from the standards documents 
themselves. 


An example of such a roadmap is "Introduction to Version 3 of the 
Internet-standard Network Management Framework" [RFC2570]. 


2.2. Applicability Statement 


SNMP is used in networks that vary widely in size and complexity, by 
organizations that vary widely in their requirements of management. 
Some models will be designed to address specific problems of 
management, such as message security. 


One or more documents may be written to describe the environments to 
which certain versions of SNMP or models within SNMP would be 
appropriately applied, and those to which a given model might be 
inappropriately applied. 


2.3. Coexistence and Transition 


The purpose of an evolutionary architecture is to permit new models 
to replace or supplement existing models. The interactions between 
models could result in incompatibilities, security "holes", and other 
undesirable effects. 


The purpose of Coexistence documents is to detail recognized 
anomalies and to describe required and recommended behaviors for 
resolving the interactions between models within the architecture. 


Coexistence documents may be prepared separately from model 
definition documents, to describe and resolve interaction anomalies 
between a model definition and one or more other model definitions. 


Additionally, recommendations for transitions between models may also 


be described, either in a coexistence document or in a separate 
document. 
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One such coexistance document is [SNMP-COEX], "Coexistence between 
Version 1, Version 2, and Version 3 of the Internet-standard Network 
Management Framework". 


2.4. Transport Mappings 


SNMP messages are sent over various transports. It is the purpose of 
Transport Mapping documents to define how the mapping between SNMP 
and the transport is done. 


2.5. Message Processing 


A Message Processing Model document defines a message format, which 
is typically identified by a version field in an SNMP message header. 
The document may also define a MIB module for use in message 
processing and for instrumentation of version-specific interactions. 


An SNMP engine includes one or more Message Processing Models, and 
thus may support sending and receiving multiple versions of SNMP 
messages. 


2.6. Security 


Some environments require secure protocol interactions. Security is 
normally applied at two different stages: 


- in the transmission/receipt of messages, and 
- in the processing of the contents of messages. 


For purposes of this document, "security" refers to message-level 
security; "access control" refers to the security applied to protocol 
operations. 


Authentication, encryption, and timeliness checking are common 
functions of message level security. 


A security document describes a Security Model, the threats against 
which the model protects, the goals of the Security Model, the 
protocols which it uses to meet those goals, and it may define a MIB 
module to describe the data used during processing, and to allow the 
remote configuration of message-level security parameters, such as 
keys. 


An SNMP engine may support multiple Security Models concurrently. 
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2.7. Access Control 


During processing, it may be required to control access to managed 
objects for operations. 


An Access Control Model defines mechanisms to determine whether 
access to a managed object should be allowed. An Access Control 


Model 


may define a MIB module used during processing and to allow the 


remote configuration of access control policies. 


2.8. Protocol Operations 
SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). SNMP 
PDUs define the operations performed by the receiving SNMP engine. 
It is the purpose of a Protocol Operations document to define the 
operations of the protocol with respect to the processing of the 
PDUs. Every PDU belongs to one or more of the PDU classes defined 
below: 
1) Read Class: 
The Read Class contains protocol operations that retrieve 
management information. For example, RFC 1905 defines the 
following protocol operations for the Read Class: GetRequest-— 
PDU, GetNextRequest-PDU, and GetBulkRequest-PDU. 
2) Write Class: 
The Write Class contains protocol operations which attempt to 
modify management information. For example, RFC 1905 defines 
the following protocol operation for the Write Class: 
SetRequest-PDU. 
3) Response Class: 
The Response Class contains protocol operations which are sent 
in response to a previous request. For example, RFC 1905 
defines the following for the Response Class: Response-PDU, 
Report-PDU. 
4) Notification Class: 


The Notification Class contains protocol operations which send 
a notification to a notification receiver application. For 
example, RFC 1905 defines the following operations for the 
Notification Class: Trapv2-PDU, InformRequest-PDU. 
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5) Internal Class: 


The Internal Class contains protocol operations which are 


exchanged internally between SNMP engines. For example, RFC 
1905 defines the following operations for the Internal Class: 
Report-PDU. 


The preceding five classifications are based on the functional 
properties of a PDU. It is also useful to classify PDUs based on 
whether a response is expected: 


6) Confirmed Class: 


The Confirmed Class contains all protocol operations which 
Cause the receiving SNMP engine to send back a response. For 
example, RFC 1905 defines the following operations for the 
Confirmed Class: GetRequest-PDU, GetNextRequest-PDU, 
GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU. 


7) Unconfirmed Class: 


The Unconfirmed Class contains all protocol operations which 
are not acknowledged. For example, RFC 1905 defines the 
following operations for the Unconfirmed Class:  Report-PDU, 
Trapv2-PDU, and GetResponse-PDU. 


An application document defines which Protocol Operations are 
supported by the application. 


2.9. Applications 


An SNMP entity normally includes a number of applications. 
Applications use the services of an SNMP engine to accomplish 
specific tasks. They coordinate the processing of management 
information operations, and may use SNMP messages to communicate with 
other SNMP entities. 


Applications documents describe the purpose of an application, the 
services required of the associated SNMP engine, and the protocol 
operations and informational model that the application uses to 
perform management operations. 


An application document defines which set of documents are used to 
specifically define the structure of management information, textual 
conventions, conformance requirements, and operations supported by 
the application. 
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2.10. Structure of Management Information 


Management information is viewed as a collection of managed objects, 
residing in a virtual information store, termed the Management 
Information Base (MIB). Collections of related objects are defined in 
MIB modules. 


It is the purpose of a Structure of Management Information document 
to establish the notation for defining objects, modules, and other 
elements of managed information. 


2.11. Textual Conventions 


When designing a MIB module, it is often useful to define new types 
similar to those defined in the SMI, but with more precise semantics, 
or which have special semantics associated with them. These newly 
defined types are termed textual conventions, and may be defined in 
separate documents, or within a MIB module. 


2.12. Conformance Statements 


It may be useful to define the acceptable lower-bounds of 
implementation, along with the actual level of implementation 
achieved. It is the purpose of the Conformance Statements document to 
define the notation used for these purposes. 


2.13. Management Information Base Modules 


MIB documents describe collections of managed objects which 
instrument some aspect of a managed node. 


2.13.1. SNMP Instrumentation MIBs 


An SNMP MIB document may define a collection of managed objects which 
instrument the SNMP protocol itself. In addition, MIB modules may be 
defined within the documents which describe portions of the SNMP 
architecture, such as the documents for Message processing Models, 
Security Models, etc. for the purpose of instrumenting those Models, 
and for the purpose of allowing remote configuration of the Model. 


2.14. SNMP Framework Documents 


This architecture is designed to allow an orderly evolution of 
portions of SNMP Frameworks. 


Throughout the rest of this document, the term "subsystem" refers to 


an abstract and incomplete specification of a portion of a Framework, 
that is further refined by a model specification. 
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A "model" describes a specific design of a subsystem, defining 
additional constraints and rules for conformance to the model. A 
model is sufficiently detailed to make it possible to implement the 
specification. 


An "implementation" is an instantiation of a subsystem, conforming to 
one or more specific models. 


SNMP version 1 (SNMPv1), is the original Internet-standard Network 
Management Framework, as described in RFCs 1155, 1157, and 1212. 


SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the 
SNMPv1 Framework. It is described in STD 58, RFCs 2578, 2579, 2580, 
and RFCs 1905-1907. SNMPv2 has no message definition. 

The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP 
Framework which supplements the SNMPv2 Framework, as described in RFC 
1901. It adds the SNMPv2c message format, which is similar to the 
SNMPvl message format. 


SNMP version 3 (SNMPv3), is an extensible SNMP Framework which 
supplements the SNMPv2 Framework, by supporting the following: 


- a new SNMP message format, 

- Security for Messages, 

- Access Control, and 

- Remote configuration of SNMP parameters. 
Other SNMP Frameworks, i.e., other configurations of implemented 
subsystems, are expected to also be consistent with this 
architecture. 


3. Elements of the Architecture 


This section describes the various elements of the architecture and 
how they are named. There are three kinds of naming: 


1) the naming of entities, 
2) the naming of identities, and 


3) the naming of management information. 
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This architecture also defines some names for other constructs that 
are used in the documentation. 

3.1. The Naming of Entities 
An SNMP entity is an implementation of this architecture. Each such 
SNMP entity consists of an SNMP engine and one or more associated 


applications. 


The following figure shows details about an SNMP entity and the 
components within it. 


SNMP engine (identified by snmpEnginelD) 


| | 
| | 
| +------------ + +------------ + +----------- + +----------- + | 
| | | | | | | | | | 
| | Dispatcher | | Message | | Security | | Access | | 
Processing Subsystem Control 
Subsystem Subsystem 
| | | ae 
|  +------------ + +------------ + +----------- + +----------- + | 
| | 
4+-------------------------- - - - - - - $5 5 5 ee + 
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+ 


| 
| 
|  +------------- + +-------------- + +-------------- + | 
| | Command | | Notification | | Proxy | 
| Generator | | Receiver | | Forwarder 
+------------- + +-------------- + +-------------- + 
| | 
| +------------- + +-------------- + +-------------- + | 
| | Command | | Notification | | Other | 
| | Responder | | Originator | | 
+------------- + +-------------- + +-------------- + 
+------------------------------------------------------------- + 
HO 5 55 555 5 5 5555 55 5 5555 55 55555555 n--- + 
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3.1.1. SNMP engine 


An SNMP engine provides services for sending and receiving messages, 
authenticating and encrypting messages, and controlling access to 
managed objects. There is a one-to-one association between an SNMP 
engine and the SNMP entity which contains it. 


The engine contains: 
1) a Dispatcher, 
2) a Message Processing Subsystem, 
3) a Security Subsystem, and 
4) an Access Control Subsystem. 
3.1.1.1. snmpEngineID 
Within an administrative domain, an snmpEngineID is the unique and 
unambiguous identifier of an SNMP engine. Since there is a one-to-one 
association between SNMP engines and SNMP entities, it also uniquely 
and unambiguously identifies the SNMP entity within that 
administrative domain. Note that it is possible for SNMP entities in 
different administrative domains to have the same value for 
snmpEngineID. Federation of administrative domains may necessitate 
assignment of new values. 
3.1.1.2. Dispatcher 
There is only one Dispatcher in an SNMP engine. It allows for 
concurrent support of multiple versions of SNMP messages in the SNMP 
engine. It does so by: 


- sending and receiving SNMP messages to/from the network, 


- determining the version of an SNMP message and interacting with 
the corresponding Message Processing Model, 


- providing an abstract interface to SNMP applications for 
delivery of a PDU to an application. 


- providing an abstract interface for SNMP applications that 
allows them to send a PDU to a remote SNMP entity. 
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3.1.1.3. Message Processing Subsystem 


The Message Processing Subsystem is responsible for preparing 
messages for sending, and extracting data from received messages. 


The Message Processing Subsystem potentially contains multiple 
Message Processing Models as shown in the next figure. 


* One or more Message Processing Models may be present. 


| | 

| | 

| | 

| +------------ + +------------ + +------------ + +------------ + | 

* * * * 

| SNMPv3 SNMPv1 SNMPv2c Other 

| | Message | | Message | | Message | | Message | | 

| | Processing | | Processing | | Processing | | Processing | | 

| | Model | | Model | | Model | | Model | 

al ml Hl. 2 i al | | 
$ A SaaS =a ai A E T + 

S O O O O E + 


3.1.1.3.1. Message Processing Model 
Each Message Processing Model defines the format of a particular 
version of an SNMP message and coordinates the preparation and 
extraction of each such version-specific message format. 
3.1.1.4. Security Subsystem 
The Security Subsystem provides security services such as the 


authentication and privacy of messages and potentially contains 
multiple Security Models as shown in the following figure 
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* One or more Security Models may be present. 


| | 
| | 
| | 
|  +---------------- fo ope See ee. Sa ese 5 Sees ee Sse ee eS + | 
| | ell i] mall g =j 
User-Based Other Other 
| | Security | | Security | | Security | 
| | Model | | Model | | Model | 
| | | | | | | | 
| +---------------- $  $----------------- eS ee e + | 
| | 
+------------------------------------------------ = --- = == + 


3.1.1.4.1. Security Model 
A Security Model specifies the threats against which it protects, the 
goals of its services, and the security protocols used to provide 
security services such as authentication and privacy. 

3.1.1.4.2. Security Protocol 
A Security Protocol specifies the mechanisms, procedures, and MIB 
objects used to provide a security service such as authentication or 
privacy. 


3.1.2. Access Control Subsystem 


The Access Control Subsystem provides authorization services by means 
of one or more (*) Access Control Models. 


| | 
| | 
| | 
|  +--------------- # “pee Sessesseoussess ff, opioides + | 
| | a d sal Kai ol 
View-Based Other Other 
| | Access | | Access | | Access | 
| | Control | | Control | | Control | 
| | Model | | Model | | Model | 
| | | | | | | | 
| 4+--------------- + 9 +---------------—- + — +------------------ + | 
| | 
HO - - -- --- -- - -- - -- = - + 
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3.1.2.1. Access Control Model 


An Access Control Model defines a particular access decision function 
in order to support decisions regarding access rights. 


3.1.3. Applications 
There are several types of applications, including: 


- command generators, which monitor and manipulate management 
data, 


- command responders, which provide access to management data, 
- notification originators, which initiate asynchronous messages, 


- notification receivers, which process asynchronous messages, 
and 


- proxy forwarders, which forward messages between entities. 


These applications make use of the services provided by the SNMP 
engine. 


3.1.3.1. SNMP Manager 
An SNMP entity containing one or more command generator and/or 


notification receiver applications (along with their associated SNMP 
engine) has traditionally been called an SNMP manager. 
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* One or more models may be present. 


(traditional SNMP manager) 


BO 5 5 + 
| +-------------- + +-------------- + +-------------- + SNMP entity | 
| | NOTIFICATION | | NOTIFICATION | | COMMAND | 
| | ORIGINATOR | | RECEIVER | | GENERATOR | 
| | applications | | applications | | applications | | 
| +-------------- + +-------------- + +-------------- + 
| | | | | 
| v v v | 
| +------—- +-------- +----------------- + | 
| | +--------------------- + +---------------- + | 
| | Message Processing Security 
Dispatcher v Subsystem Subsystem 
o tf 4e- + || | | 
| | PDU Dispatcher | | +->| v1MP * | <---> | id er fon + | 
| | O + | | | other ||| 
| | E + | | | security | | | 
+->| v2cMP * |<--->| | Model 
| | Message | | | FSA SSSSS SASS + | A + | 
| | Dispatcher <--------- >+ | | | 
|| E El + | | 
| | | | +->| v3MP * |<--->| | User-based | | | 
| | Transport | | | +------------ + | | Security | 
Mapping | +------------ + | | Model 
(e.g RFC1906) +->| otherMP * |<--->| +------------ + 
A El 4- + | | | | 
| 2 $--------------------- + +---------------- + | 
| | | 
| v | 
BO + 
+----- + +----- + +------- + 
| upp | | 1PX | | other | 
+----- + +----- + +------- + 
| | | 
v v v 
+------------------------------ + 
| Network | 
+------------------------------ + 
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3.1.3.2. SNMP Agent 


An SNMP entity containing one or more command responder and/or 
notification originator applications (along with their associated 
SNMP engine) has traditionally been called an SNMP agent. 


$ O O EE A a E AEE + 
| Network | 
$ O + 
| | | 
v v v 
feos se he So + doo + 
| upp | | 1PX | | other | 
+----- + 4----- + +------- + (traditional SNMP agent) 
Sa a et + 
| Ho + +---------------- + 
| | | Message Processing | | Security | 
| Dispatcher v | Subsystem | Subsystem | 
[4 as + | | | | 
| | Transport | | a. v1MP * |<--->| oH airna + | 
Mapping. <- 5. J | (U sses + Other | 
| | (e.g. RFC1906) o + Security 
| | | | +->| v2cMP * |<--->| | Model | | 
| | Message | | | PSS See + | | +------------ + | 
| | Dispatcher <--------- >| +------------ + | +------------ + | 
| | | | +->| v3mp * |<--->| | User-based | | | 
HS 22226 + Security 
| PDU Dispatcher | pes += === + | | Model | 
| +------------------- + | +->| otherMP * |<--->| +------------ + | | 
| A | 4- + | | | | 
| | $--------------------- + +---------------- + | 
| v | 
| Ho -- $---------- === === += === 4 === === ----- + | 
| | | | 
| v v v 
| +------------- +  +--------- +  +-=------------- + 0 $------------- + | 
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | | 
| RESPONDER <->| CONTROL |<-> ORIGINATOR FORWARDER | 
application applications application 
| +------------- +  +--------—- + A -------- + +------------- + | 
| ^ Ñ | 
| | | | 
| v v | 
o + 
| MIB instrumentation SNMP entity 
poe Se SS O ee ee Se ee o eee eee + 
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3.2. The Naming of Identities 


principal 
| 
| 
$---------------------------- | ------------- + 
| SNMP engine v 
| $-------------- + | 
| | 
| +----------------- | securityName |---+ | 
| | Security Model | | | | 
| | t-----------—-- + | | 
| | a ol 
| | | | 
v 
An pl 
| | | i ih 
| | | Model Hi i 
| | | Dependent | | | 
| | | Security ID i ul 
| | 
le ee | 
| | e | | 
| | | || 
o |---------- + | 
| | | 
| | 
E a = | === + 
| 
v 
network 


3.2.01. Principal 


A principal is the "who" on whose behalf services are provided or 
processing takes place. 


A principal can be, among other things, an individual acting in a 
particular role; a set of individuals, with each acting in a 
particular role; an application or a set of applications; and 
combinations thereof. 


3.2.2. securityName 
A securityName is a human readable string representing a principal. 


It has a model-independent format, and can be used outside a 
particular Security Model. 
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3.2.3. Model-dependent security ID 


A model-dependent security ID is the model-specific representation of 
a securityName within a particular Security Model. 


Model-dependent security IDs may or may not be human readable, and 


have a model-dependent syntax. Examples include community names, and 
user names. 


The transformation of model-dependent security IDs into securityNames 
and vice versa is the responsibility of the relevant Security Model. 
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Management information resides at an SNMP entity where a Command 
Responder Application has local access to potentially multiple 


contexts. 


This application uses a contextEngineID equal to the 


snmpEngineID of its associated SNMP engine. 


+ A A A E AA A A E IR A E SR RA E ea A E A E SA 
SNMP entity (identified by snmpEngineID, example: abcd) 
| +------------------------------------------------------------ + 
| | SNMP engine (identified by snmpEngineID) 
| | | 
| | +------------- + +------------ + +----------- + +----------- + | 
a |] |] |] |] 
Dispatcher Message Security Access 
| | | | | Processing | | Subsystem | | Control | | 
| | | | | Subsystem | | Subsystem | | 
| | | | | | | | 
| | +------------- + +------------ + +----------- + +----------- + | 
Il | 
i o + 
|  +------------------------------------------------------------ + 
| | Command Responder Application 
| | (contextEngineID, example: abcd) 
| | | 
| | example contextNames: | 
| | "bridgel" "bridge2" "" (default) | 
O (ee rer | 
| | | | | | 
A |------------------ |------------------- |-------------- + 
A anna nnn Late A , 
| | MIB | instrumentation | | | 
| | +---v------------ + $---y------------ + $----y----------- + | 
| | | context | context | | context | 
| | | | |] lr 4] 
His + HS + > Hao + Hs + Habitat + 
| | | bridge MIB | | bridge MIB | | some MIB | 
bok! Uh eseeeorss == ar AM lara PN ess eae et el fl 
IA L | | | | A 
na | | | | 4------------ +| | 
Et N || | | | other ms | | | 
| | | nn AM 
+ SS A A A A A A A A SS Se A A AS AO eS 
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3.3.1. An SNMP Context 


An SNMP context, or just "context" for short, is a collection of 
management information accessible by an SNMP entity. An item of 
management information may exist in more than one context. An SNMP 
entity potentially has access to many contexts. 


Typically, there are many instances of each managed object type 
within a management domain. For simplicity, the method for 
identifying instances specified by the MIB module does not allow each 
instance to be distinguished amongst the set of all instances within 
a management domain; rather, it allows each instance to be identified 
only within some scope or "context", where there are multiple such 
contexts within the management domain. Often, a context is a 
physical device, or perhaps, a logical device, although a context can 
also encompass multiple devices, or a subset of a single device, or 
even a subset of multiple devices, but a context is always defined as 
a subset of a single SNMP entity. Thus, in order to identify an 
individual item of management information within the management 
domain, its contextName and contextEngineID must be identified in 
addition to its object type and its instance. 


For example, the managed object type ifDescr [RFC2233], is defined as 
the description of a network interface. To identify the description 
of device-X’s first network interface, four pieces of information are 
needed: the snmpEngineID of the SNMP entity which provides access to 
the management information at device-X, the contextName (device-X), 
the managed object type (ifDescr), and the instance ("1"). 


Each context has (at least) one unique identification within the 
management domain. The same item of management information can exist 
in multiple contexts. An item of management information may have 
multiple unique identifications. This occurs when an item of 
management information exists in multiple contexts, and this also 
occurs when a context has multiple unique identifications. 


The combination of a contextEngineID and a contextName unambiguously 
identifies a context within an administrative domain; note that there 
may be multiple unique combinations of contextEngineID and 
contextName that unambiguously identify the same context. 


3.3.2. contextEngineID 
Within an administrative domain, a contextEngineID uniquely 


identifies an SNMP entity that may realize an instance of a context 
with a particular contextName. 


SNMPv3 Working Group Standards Track [Page 26] 


RFC 2571 Architecture for SNMP Frameworks April 1999 


3.3.3. contextName 


A contextName is used to name a context. Each contextName MUST be 
unique within an SNMP entity. 


3.3.4.  scopedPDU 


A scopedPDU is a block of data containing a contextEnginelD, a 
contextName, and a PDU. 


The PDU is an SNMP Protocol Data Unit containing information named in 
the context which is unambiguously identified within an 
administrative domain by the combination of the contextEngineID and 
the contextName. See, for example, RFC1905 for more information about 
SNMP PDUs. 

3.4. Other Constructs 

3.4.1. maxSizeResponseScopedPDU 
The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that 
a PDU’s sender would be willing to accept. Note that the size of a 
scopedPDU does not include the size of the SNMP message header. 


3.4.2. Local Configuration Datastore 


The subsystems, models, and applications within an SNMP entity may 
need to retain their own sets of configuration information. 


Portions of the configuration information may be accessible as 
managed objects. 


The collection of these sets of information is referred to as an 
entity's Local Configuration Datastore (LCD). 


3.4.3. securityLevel 
This architecture recognizes three levels of security: 
= without authentication and without privacy (noAuthNoPriv) 
- with authentication but without privacy (authNoPriv) 
- with authentication and with privacy (authPriv) 


These three values are ordered such that noAuthNoPriv is less than 
authNoPriv and authNoPriv is less than authPriv. 
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Every message has an associated securityLevel. All Subsystems 
(Message Processing, Security, Access Control) and applications are 
REQUIRED to either supply a value of securityLevel or to abide by the 
supplied value of securityLevel while processing the message and its 
contents. 


4. Abstract Service Interfaces 


Abstract service interfaces have been defined to describe the 
conceptual interfaces between the various subsystems within an SNMP 
entity. The abstract service interfaces are intended to help clarify 
the externally observable behavior of SNMP entities, and are not 
intended to constrain the structure or organization of 
implementations in any way. Most specifically, they should not be 
interpreted as APIs or as requirements statements for APIs. 


These abstract service interfaces are defined by a set of primitives 
that define the services provided and the abstract data elements that 
are to be passed when the services are invoked. This section lists 
the primitives that have been defined for the various subsystems. 


4.1. Dispatcher Primitives 
The Dispatcher typically provides services to the SNMP applications 
via its PDU Dispatcher. This section describes the primitives 
provided by the PDU Dispatcher. 


4.1.1. Generate Outgoing Request or Notification 


The PDU Dispatcher provides the following primitive for an 
application to send an SNMP Request or Notification to another SNMP 


entity: 
statusInformation = -- sendPduHandle if success 
-- errorIndication if failure 

sendPdu ( 
IN transportDomain -- transport domain to be used 
IN transportAddress -- transport address to be used 
IN messageProcessingModel -=- typically, SNMP version 
IN securityModel -- Security Model to use 
IN securityName -- on behalf of this principal 
IN securityLevel -- Level of Security requested 
IN contextEnginelD -- data from/at this entity 
IN contextName -- data from/in this context 
IN pduVersion -- the version of the PDU 
IN PDU -- SNMP Protocol Data Unit 
IN expectResponse -- TRUE or FALSE 


) 
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4.1.2. Process Incoming Request or Notification PDU 


The PDU Dispatcher provides the following primitive to pass an 


incoming SNMP PDU to an application: 


processPdu ( 
IN messageProcessingModel 
IN securityModel 
IN securityName 
IN securityLevel 
IN contextEngineID 
IN contextName 
IN pduVersion 
IN PDU 
IN maxSizeResponseScopedPDU 
IN stateReference 
) 
4.1.3. Generate Outgoing Response 


process Request/Notification PDU 
typically, SNMP version 

Security Model in use 

on behalf of this principal 
Level of Security 

data from/at this SNMP entity 
data from/in this context 

the version of the PDU 

SNMP Protocol Data Unit 

maximum size of the Response PDU 
reference to state information 
needed when sending a response 


The PDU Dispatcher provides the following primitive for an 
application to return an SNMP Response PDU to the PDU Dispatcher: 


result = 

returnResponsePdu ( 
messageProcessingModel 
securityModel 
securityName 
securityLevel 
contextEngineID 
contextName 

pduVersion 

PDU 
maxSizeResponseScopedPDU 
stateReference 


HHHHHHHHHH 
ZZZZZZZZZZ 


H 
Z 


statusInformation 


) 


4.1.4. Process Incoming Response PDU 


SUCCESS or FAILURE 


typically, SNMP version 
Security Model in use 

on behalf of this principal 
same as on incoming request 
data from/at this SNMP entity 
data from/in this context 

the version of the PDU 

SNMP Protocol Data Unit 
maximum size sender can accept 
reference to state information 
as presented with the request 
success or errorIndication 
error counter OID/value if error 


The PDU Dispatcher provides the following primitive to pass an 
incoming SNMP Response PDU to an application: 
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processResponsePdu ( -=- process Response PDU 
IN messageProcessingModel -—- typically, SNMP version 
IN securityModel -- Security Model in use 
IN securityName -- on behalf of this principal 
IN securityLevel -- Level of Security 
IN contextEnginelD -- data from/at this SNMP entity 
IN contextName -- data from/in this context 
IN pduVersion -- the version of the PDU 
IN PDU -- SNMP Protocol Data Unit 
IN statusInformation -=- success or errorIndication 
IN sendPduHandle -- handle from sendPdu 


) 
4.1.5. Registering Responsibility for Handling SNMP PDUs 


Applications can register/unregister responsibility for a specific 
contextEngineID, for specific pduTypes, with the PDU Dispatcher 
according to the following primitives. The list of particular 
pduTypes that an application can register for is determined by the 
Message Processing Model(s) supported by the SNMP entity that 
contains the PDU Dispatcher. 


statusInformation = —- success or errorIndication 
registerContextEnginelD ( 
IN contextEnginelD -- take responsibility for this one 
IN pduType -- the pduType(s) to be registered 


) 


unregisterContextEnginelD ( 
IN contextEngineID -- give up responsibility for this one 
IN pduType -- the pduType(s) to be unregistered 
) 


Note that realizations of the registerContextEnginelD and 
unregisterContextEngineID abstract service interfaces may provide 
implementation-specific ways for applications to register/deregister 
responsibility for all possible values of the contextEnginelD or 
pduType parameters. 


4.2. Message Processing Subsystem Primitives 
The Dispatcher interacts with a Message Processing Model to process a 


specific version of an SNMP Message. This section describes the 
primitives provided by the Message Processing Subsystem. 
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4.2.1. Prepare Outgoing SNMP Request or Notification Message 


The Message Processing Subsystem provides this service primitive for 
preparing an outgoing SNMP Request or Notification Message: 


statusInformation = 
prepareOutgoingMessage ( 


IN transportDomain 
IN transportAddress 
IN messageProcessingModel 
IN securityModel 

IN securityName 

IN securityLevel 

IN contextEngineID 
IN contextName 

IN pduVersion 

IN PDU 

IN expectResponse 
IN sendPduHandle 


OUT destTransportDomain 

OUT destTransportAddress 

OUT outgoingMessage 

OUT outgoingMessageLength 
) 


success or errorIndication 


transport domain to be used 
transport address to be used 
typically, SNMP version 
Security Model to use 

on behalf of this principal 
Level of Security requested 
data from/at this entity 
data from/in this context 
the version of the PDU 

SNMP Protocol Data Unit 

TRUE or FALSE 

the handle for matching 
incoming responses 
destination transport domain 
destination transport address 
the message to send 

its length 


4.2.2. Prepare an Outgoing SNMP Response Message 


The Message Processing Subsystem provides this service primitive for 
preparing an outgoing SNMP Response Message: 


result = 
prepareResponseMessage ( 


IN messageProcessingModel 
IN securityModel 

IN securityName 

IN securityLevel 

IN contextEngineID 

IN contextName 

IN pduVersion 

IN PDU 

IN maxSizeResponseScopedPDU 
IN stateReference 

IN statusInformation 

OUT destTransportDomain 
OUT destTransportAddress 
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SUCCESS or FAILURE 


typically, SNMP version 

same as on incoming request 
same as on incoming request 
same as on incoming request 
data from/at this SNMP entity 
data from/in this context 

the version of the PDU 

SNMP Protocol Data Unit 
maximum size able to accept 
reference to state information 
as presented with the request 
success or errorIndication 
error counter OID/value if error 
destination transport domain 
destination transport address 
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OUT outgoingMessage -- the message to send 
OUT outgoingMessageLength -—- its length 
) 
4.2.3. Prepare Data Elements from an Incoming SNMP Message 


The Message Processing Subsystem provides this service primitive for 
preparing the abstract data elements from an incoming SNMP message: 


result 


prepareDataElements ( 


IN 

IN 

IN 

IN 

OUT 
OUT 
OUT 
OUT 
OUT 
OUT 
OUT 
OUT 
OUT 
OUT 
OUT 
OUT 


OUT 


transportDomain 
transportAddress 
wholeMsg 
wholeMsgLength 
messageProcessingModel 
securityModel 
securityName 
securityLevel 
contextEngineID 
contextName 

pduVersion 

PDU 

pduType 

sendPduHandle 
maxSizeResponseScopedPDU 
statusInformation 


stateReference 


) 


SUCCESS or errorIndication 


origin transport domain 

origin transport address 

as received from the network 

as received from the network 
typically, SNMP version 

Security Model to use 

on behalf of this principal 
Level of Security requested 

data from/at this entity 

data from/in this context 

the version of the PDU 

SNMP Protocol Data Unit 

SNMP PDU type 

handle for matched request 
maximum size sender can accept 
success or errorIndication 

error counter OID/value if error 
reference to state information 
to be used for possible Response 


4.3. Access Control Subsystem Primitives 


Applications are the typical clients of the service(s) of the Access 
Control Subsystem. 


The following primitive is provided by the Access Control Subsystem 
to check if access is allowed: 
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statusInformation = -=- success or errorIndication 
isAccessAllowed ( 
IN securityModel -- Security Model in use 
IN securityName -=- principal who wants to access 
IN securityLevel -- Level of Security 
IN viewType -- read, write, or notify view 
IN contextName -=- context containing variableName 
IN variableName -—- OID for the managed object 

) 
4.4. Security Subsystem Primitives 


The Message Processing Subsystem is the typical client of the 
services of the Security Subsystem. 


4.4.1. Generate a Request or Notification Message 


The Security Subsystem provides the following primitive to generate a 
Request or Notification message: 


statusInformation = 
generateRequestMsg ( 


IN messageProcessingModel —- typically, SNMP version 
IN globalData -- message header, admin data 
IN maxMessageSize -- of the sending SNMP entity 
IN securityModel -=- for the outgoing message 
IN securityEnginelD -- authoritative SNMP entity 
IN securityName -- on behalf of this principal 
IN securityLevel -- Level of Security requested 
IN scopedPDU -- message (plaintext) payload 
OUT securityParameters -- filled in by Security Module 
OUT wholeMsg -- complete generated message 
OUT wholeMsgLength -- length of the generated message 
) 
4.4.2. Process Incoming Message 


The Security Subsystem provides the following primitive to process an 
incoming message: 
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4. 


4. 


SNMPv3 Working Group 


4. 


Ds 


statusInformation 


processIncomingMsg ( 


securityModel a 
securitylLlevel -- 
wholeMsg == 
wholeMsgLength 7 
securityEnginelD E 
securityName == 
scopedPDU, == 
maxSizeResponseScopedPDU -- 
securityStateReference == 
) == 


22222224 


U 


OCOOCOOHHHHHHH 


C 
HAAAA 


3. Generate a Response Message 


The Security Subsystem provides the 
Response message: 


statusInformation 
generateResponseMsg ( 


IN messageProcessingModel ahs 
IN globalData += 
IN maxMessageSize E 
IN securityModel == 
IN securityEngineID == 
IN securityName =F 
IN securityLevel == 
IN scopedPDU => 
IN securityStateReference == 
OUT securityParameters == 
OUT wholeMsg ==> 
OUT wholeMsgLength -- 


) 
Common Primitives 


These primitive (s) 
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messageProcessingModel == 
maxMessageSize == 
securityParameters == 
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errorIndication or success 
error counter OID/value if error 


typically, SNMP version 

of the sending SNMP entity 

for the received message 

for the received message 

Level of Security 

as received on the wire 

length as received on the wire 
identification of the principal 
identification of the principal 
message (plaintext) payload 
maximum size sender can handle 
reference to security state 
information, needed for response 


following primitive to generate a 


typically, SNMP version 

message header, admin data 

of the sending SNMP entity 

for the outgoing message 
authoritative SNMP entity 

on behalf of this principal 

for the outgoing message 
message (plaintext) payload 
reference to security state 
information from original request 
filled in by Security Module 
complete generated message 
length of the generated message 


are provided by multiple Subsystems. 


[Page 34] 


RFC 2571 Architecture for SNMP Frameworks April 1999 


4.5.1. Release State Reference Information 


All Subsystems which pass stateReference information also provide a 


primitive to release the memory that holds the referenced state 
information: 


stateRelease ( 
IN stateReference 


) 


-=-- handle of reference to be released 
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4.6. Scenario Diagrams 
4.6.1. Command Generator or Notification Originator 
This diagram shows how a Command Generator or Notification Originator 


application requests that a PDU be sent, and how the response is 
returned (asynchronously) to that application. 


Command Dispatcher Message Security 
Generator | Processing Model 
| | Model | 
| sendPdu | | | 
| ------=--=--=--=--- >| | | 
| | prepareOutgoingMessage | 
A >| | 
| | generateRequestMsg 
aaa A ers AE EA > 
| | | 
| io ES ara | 
| | | 
a SN | | 
as Po | 
| Send SNMP | | | 
| Request Message | | | 
| to Network | | 
| v | | 
| | | | 
| Receive SNMP | | | 
| Response Message | | | 
from Network | 
<----------------- + 
| | | 
| prepareDataElements | | 
SE ES >| | 
| processIncomingMsg | 
| A A i hr > 
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4.6.2. Scenario Diagram for a Command Responder Application 


This diagram shows how a Command Responder or Notification Receiver 
application registers for handling a pduType, how a PDU is dispatched 
to the application after a SNMP message is received, and how the 
Response is (asynchronously) send back to the network. 


Command Dispatcher Message Security 
Responder Processing Model 
Model 


| registerContextEnginelD | 


| 
| | 
o >| | | 
| <---n oan nnn nnn | Bo N | 
| | Receive SNMP | | | 
: | Message 
from Network 

a = | | 
| | | 
pas | | 
no > | 

| | processIncomingMsg 

A A AE a > 
| | | 
| | o | 
| | | 
| <-------- ==" ==" ==" | | 
processPdu 

eal eens | | | 
| 


| | | 
a Poy eee eg ey ee AA A ee ee) > 
prepareResponseMsg | | 
tee aaa ean >| | 
| | generateResponseMsg | 
| p >| 
| | | 
| a | 
eeens | | 
| | | 
(pees + | | 
| Send SNMP | | | 
Message 
to Network 
| v | | 
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5. Managed Object Definitions for SNMP Management Frameworks 


SNMP-FRAMEWORK-MIB DEFINITIONS ::= 


IMPORTS 


BEGIN 


MODULE-IDENTITY, OBJECT-TYPE, 
OBJECT-IDENTITY, 


snmpModules 


TEXTUAL-CONVENTION 


MODULE-COMPLIANCE, 


snmpFrameworkMIB 
LAST-UPDATED 
ORGANIZATION 
CONTACT-INFO 


SNMPv3 Working Group 


OBJECT-GROUP 


FROM SNMPv2-SMI 
FROM SNMPv2-TC 
FROM SNMPv2-CONF'; 


MODULE-IDENTITY 


"99011900002" 


-- 19 January 1999 


"SNMPv3 Working Group" 


"WG-EMail: 


Subscribe: 


Chair: 
postal: 
EMail: 
phone: 
Co-editor 


postal: 


EMail: 
phone: 


Co-editor 


postal: 


EMail: 
phone: 


Co-editor: 


postal: 


Standards Track 


snmpv3@tis.com 
majordomo@tis.com 
In message body: subscribe snmpv3 
Russ Mundy 

TIS Labs at Network Associates 
3060 Washington Rd 

Glenwood MD 21738 

USA 

mundy@tis.com 

+1 301-854-6889 


Dave Harrington 
Cabletron Systems, Inc. 
Post Office Box 5005 
Mail Stop: Durham 

35 Industrial Way 
Rochester, NH 03867-5005 
USA 

dbh@ctron.com 

+1 603-337-7357 


Randy Presuhn 

BMC Software, Inc. 
965 Stewart Drive 
Sunnyvale, CA 94086 
USA 
randy_presuhn@bmc.com 
+1 408-616-3100 


Bert Wijnen 

IBM T.J. Watson Research 
Schagen 33 

3461 GL Linschoten 


1999 
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Netherlands 

EMail: wijnen@vnet.ibm.com 
phone: +31 348-432-794 
" 

DESCRIPTION "The SNMP Management Architecture MIB" 

—- Revision History 

REVISION "99011900002" -- 19 January 1999 

DESCRIPTION "Updated editors’ addresses, fixed typos. 
Published as RFC2571. 
" 

REVISION "97112000002" -- 20 November 1997 

DESCRIPTION "The initial version, published in RFC 2271. 
" 

:= { snmpModules 10 } 


—- Textual Conventions used in the SNMP Management Architecture *** 


SnmpEnginelD ::= 
STATUS 


TEXTUAL-CONVENTION 
current 


1999 


DESCRIPTION "An SNMP engine's administratively-unique identifier. 
Objects of this type are for identification, not for 


SNMPv3 Working Group 


addressing, even though it is possible that an 
address may have been used in the generation of 
a specific value. 


The value for this object may not be all zeros or 
all 'ff'H or the empty (zero length) string. 


The initial value for this object may be configured 
via an operator console entry or via an algorithmic 


function. In the latter case, the following 
example algorithm is recommended. 


In cases where there are multiple engines on the 
same system, the use of this algorithm is NOT 
appropriate, as it would result in all of those 
engines ending up with the same ID value. 


1) The very first bit is used to indicate how the 
rest of the data is composed. 


0 — as defined by enterprise using former methods 
that existed before SNMPv3. See item 2 below. 


1 - as defined by this architecture, see item 3 
below. 
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Note that this allows existing uses of the 
engineID (also known as AgentID [RFC1910]) to 
co-exist with any new uses. 


The snmpEngineID has a length of 12 octets. 


The first four octets are set to the binary 
equivalent of the agent's SNMP management 
private enterprise number as assigned by the 
Internet Assigned Numbers Authority (IANA). 

For example, if Acme Networks has been assigned 
{ enterprises 696 }, the first four octets would 
be assigned '000002b8'H. 


The remaining eight octets are determined via 
one or more enterprise-specific methods. Such 
methods must be designed so as to maximize the 
possibility that the value of this object will 
be unique in the agent's administrative domain. 
For example, it may be the IP address of the SNMP 
entity, or the MAC address of one of the 
interfaces, with each address suitably padded 
with random octets. If multiple methods are 
defined, then it is recommended that the first 
octet indicate the method being used and the 
remaining octets be a function of the method. 


The length of the octet strings varies. 


The first four octets are set to the binary 
equivalent of the agent's SNMP management 
private enterprise number as assigned by the 
Internet Assigned Numbers Authority (IANA). 

For example, if Acme Networks has been assigned 
{ enterprises 696 }, the first four octets would 
be assigned '000002b8'H. 


The very first bit is set to 1. For example, the 
above value for Acme Networks now changes to be 
/800002b8'H. 


The fifth octet indicates how the rest (6th and 
following octets) are formatted. The values for 
the fifth octet are: 


0 - reserved, unused. 
1 - IPv4 address (4 octets) 
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lowest non-special IP address 

2 - IPv6 address (16 octets) 
lowest non-special IP address 

3 - MAC address (6 octets) 
lowest IEEE MAC address, canonical 
order 

4 - Text, administratively assigned 
Maximum remaining length 27 

5 - Octets, administratively assigned 


Maximum remaining length 27 


6-127 


reserved, unused 


127-255 


as defined by the enterprise 
Maximum remaining length 27 


SYNTAX OCTET STRING (SIZE(5..32)) 
SnmpSecurityModel ::= TEXTUAL-CONVENTION 
STATUS current 


DESCRIPTION "An identifier that uniquely identifies a 


securityModel of the Security Subsystem within the 


SNMP Management Architecture. 


The values for securityModel are allocated as 


follows: 


- The zero value is reserved. 
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- Values between 1 and 255, inclusive, are reserved 


for standards-track Security Models and are 
managed by the Internet Assigned Numbers Authority 
(IANA). 

Values greater than 255 are allocated to 
enterprise-specific Security Models. An 
enterprise-specific securityModel value is defined 
to be: 


enterpriseID * 256 + security model within 
enterprise 


For example, the fourth Security Model defined by 


the enterprise whose enterpriseID is 1 would be 
260. 
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This scheme for allocation of securityModel 
values allows for a maximum of 255 standards- 
based Security Models, and for a maximum of 
255 Security Models per enterprise. 


It is believed that the assignment of new 
securityModel values will be rare in practice 
because the larger the number of simultaneously 
utilized Security Models, the larger the 

chance that interoperability will suffer. 
Consequently, it is believed that such a range 
will be sufficient. In the unlikely event that 
the standards committee finds this number to be 
insufficient over time, an enterprise number 
can be allocated to obtain an additional 255 
possible values. 


Note that the most significant bit must be zero; 
hence, there are 23 bits allocated for various 
organizations to design and define non-standard 
securityModels. This limits the ability to 

define new proprietary implementations of Security 
Models to the first 8,388,608 enterprises. 


It is worthwhile to note that, in its encoded 
form, the securityModel value will normally 
require only a single byte since, in practice, 
the leftmost bits will be zero for most messages 
and sign extension is suppressed by the encoding 
rules. 


As of this writing, there are several values 

of securityModel defined for use with SNMP or 
reserved for use with supporting MIB objects. 
They are as follows: 


O reserved for 'any” 
1 reserved for SNMPvl 
2 reserved for SNMPv2c 
3 User-Based Security Model (USM) 
" 
SYNTAX INTEGER(O .. 2147483647) 
SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION "An identifier that uniquely identifies a Message 


SNMPv3 Working Group 


Processing Model of the Message Processing 
Subsystem within a SNMP Management Architecture. 


1999 
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The values for messageProcessingModel are 
allocated as follows: 


— Values between 0 and 255, inclusive, are 
reserved for standards-track Message Processing 
Models and are managed by the Internet Assigned 
Numbers Authority (IANA). 


- Values greater than 255 are allocated to 
enterprise-specific Message Processing Models. 
An enterprise messageProcessingModel value is 
defined to be: 


enterpriseID * 256 + 
messageProcessingModel within enterprise 


For example, the fourth Message Processing Model 
defined by the enterprise whose enterpriselD 
is 1 would be 260. 


This scheme for allocating messageProcessingModel 
values allows for a maximum of 255 standards- 
based Message Processing Models, and for a 
maximum of 255 Message Processing Models per 
enterprise. 


It is believed that the assignment of new 
messageProcessingModel values will be rare 

in practice because the larger the number of 
simultaneously utilized Message Processing Models, 
the larger the chance that interoperability 
will suffer. It is believed that such a range 
will be sufficient. In the unlikely event that 
the standards committee finds this number to be 
insufficient over time, an enterprise number 
can be allocated to obtain an additional 256 
possible values. 


Note that the most significant bit must be zero; 
hence, there are 23 bits allocated for various 
organizations to design and define non-standard 
messageProcessingModels. This limits the ability 
to define new proprietary implementations of 
Message Processing Models to the first 8,388,608 
enterprises. 


It is worthwhile to note that, in its encoded 
form, the messageProcessingModel value will 
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normally require only a single byte since, in 
practice, the leftmost bits will be zero for 
most messages and sign extension is suppressed 
by the encoding rules. 


As of this writing, there are several values of 
messageProcessingModel defined for use with SNMP. 
They are as follows: 


O reserved for SNMPvl 
1 reserved for SNMPv2c 
2 reserved for SNMPv2u and SNMPv2* 
3 reserved for SNMPv3 
" 
SYNTAX INTEGER(O .. 2147483647) 
SnmpSecuritylLevel ::= TEXTUAL-CONVENTION 
STATUS current 


DESCRIPTION "A Level of Security at which SNMP messages Can be 
sent or with which operations are being processed; 
in particular, one of: 


noAuthNoPriv - without authentication and 
without privacy, 


authNoPriv - with authentication but 
without privacy, 
authPriv - with authentication and 


with privacy. 


These three values are ordered such that 
noAuthNoPriv is less than authNoPriv and 
authNoPriv is less than authPriv. 
" 
SYNTAX INTEGER { noAuthNoPriv (1), 
authNoPriv(2), 
authPriv (3) 


SnmpAdminString ::= TEXTUAL-CONVENTION 
DISPLAY-HINT "255a" 
STATUS current 


DESCRIPTION "An octet string containing administrative 
information, preferably in human-readable form. 


To facilitate internationalization, this 

information is represented using the ISO/IEC 
IS 10646-1 character set, encoded as an octet 
string using the UTF-8 transformation format 


1999 
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described in [RFC2279]. 


Since additional code points are added by 
amendments to the 10646 standard from time 
to time, implementations must be prepared to 
encounter any code point from 0x00000000 to 
OXTfffffff. Byte sequences that do not 
correspond to the valid UTF-8 encoding of a 
code point or are outside this range are 
prohibited. 


The use of control codes should be avoided. 


When it is necessary to represent a newline, 
the control code sequence CR LF should be used. 


The use of leading or trailing white space should 
be avoided. 


For code points not directly supported by user 
interface hardware or software, an alternative 
means of entry and display, such as hexadecimal, 
may be provided. 


For information encoded in 7-bit US-ASCII, 
the UTF-8 encoding is identical to the 
US-ASCII encoding. 


UTF-8 may require multiple bytes to represent a 
single character / code point; thus the length 
of this object in octets may be different from 
the number of characters encoded. Similarly, 
size constraints refer to the number of encoded 
octets, not the number of characters represented 
by an encoding. 


Note that when this TC is used for an object that 
is used or envisioned to be used as an index, then 
a SIZE restriction MUST be specified so that the 
number of sub-identifiers for any object instance 
does not exceed the limit of 128, as defined by 
[RFC1905]. 


Note that the size of an SnmpAdminString object is 
measured in octets, not characters. 


" 


SYNTAX OCTET STRING (SIZE (0..255)) 


SNMPv3 Working Group Standards Track [Page 45] 


RFC 2571 Architecture for SNMP Frameworks April 1999 


-- Administrative assignments FREE RIT RR TK RI I KK k k 


snmpFrameworkAdmin 
OBJECT IDENTIFIER 
snmpFrameworkMIBObjects 


{ snmpFrameworkMIB 1 } 


OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } 
snmpFrameworkMIBConformance 
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } 


ae the snmpEngine Group KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } 
snmpEngineID OBJECT-TYPE 

SYNTAX SnmpEngineID 

MAX-ACCESS read-only 

STATUS current 


DESCRIPTION "An SNMP engine's administratively-unique identifier. 


::= { snmpEngine 1 } 


snmpEngineBoots OBJECT-TYPE 


SYNTAX INTEGER (1..2147483647) 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION "The number of times that the SNMP engine has 
(re-) initialized itself since snmpEnginelD 
was last configured. 


:= { snmpEngine 2 } 


snmpEngineTime OBJECT-TYPE 


SYNTAX INTEGER (0..2147483647) 
UNITS "seconds" 

MAX-ACCESS read-only 

STATUS current 


DESCRIPTION "The number of seconds since the value of 
the snmpEngineBoots object last changed. 
When incrementing this object’s value would 
cause it to exceed its maximum, 
snmpEngineBoots is incremented as if a 
re-initialization had occurred, and this 
object’s value consequently reverts to zero. 


:= { snmpEngine 3 } 


snmpEngineMaxMessageSize OBJECT-TYPE 
SYNTAX INTEGER (484..2147483647) 
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MAX-ACCESS read-only 

STATUS current 

DESCRIPTION "The maximum length in octets of an SNMP message 
which this SNMP engine can send or receive and 
process, determined as the minimum of the maximum 
message size values supported among all of the 
transports available to and supported by the engine. 


::= [ snmpEngine 4 } 


-- Registration Points for Authentication and Privacy Protocols ** 


snmpAuthProtocols OBJECT-IDENTITY 
STATUS current 
DESCRIPTION "Registration point for standards-track 
authentication protocols used in SNMP Management 


Frameworks. 
" 


::= { snmpFrameworkAdmin 1 } 


snmpPrivProtocols OBJECT-IDENTITY 
STATUS current 
DESCRIPTION "Registration point for standards-track privacy 
protocols used in SNMP Management Frameworks. 


::= { snmpFrameworkAdmin 2 } 


==: Conformance information KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


snmpFrameworkMIBCompliances 
OBJECT IDENTIFIER 
snmpFrameworkMIBGroups 
OBJECT IDENTIFIER 


{snmpFrameworkMIBConformance 1} 


{snmpFrameworkMIBConformance 2} 


-- compliance statements 


snmpFrameworkMIBCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION "The compliance statement for SNMP engines which 
implement the SNMP Management Framework MIB. 


" 


MODULE -- this module 
MANDATORY-GROUPS { snmpEngineGroup } 


::= { snmpFrameworkMIBCompliances 1 } 


-- units of conformance 
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snmpEngineGroup OBJECT-GROUP 


OBJECTS ( 
snmpEnginelD, 
snmpEngineBoots, 
snmpEngineTime, 
snmpEngineMaxMessageSize 
) 
STATUS current 


DESCRIPTION "A collection of objects for identifying and 
determining the configuration and current timeliness 
values of an SNMP engine. 


::= [ snmpFrameworkMIBGroups 1 } 


END 


6. IANA Considerations 


This document defines three number spaces administered by IANA, one 
for security models, another for message processing models, anda 
third for SnmpEngineID formats. 


6.1. Security Models 


The SnmpSecurityModel TEXTUAL-CONVENTION values managed by IANA are 
in the range from 0 to 255 inclusive, and are reserved for 
standards-track Security Models. If this range should in the future 
prove insufficient, an enterprise number can be allocated to obtain 
an additional 255 possible values. 


As of this writing, there are several values of securityModel defined 
for use with SNMP or reserved for use with supporting MIB objects. 
They are as follows: 

reserved for ‘any’ 

reserved for SNMPv1 

reserved for SNMPv2c 

User-Based Security Model (USM) 


WNHRO 


6.2. Message Processing Models 


The SnmpMessageProcessingModel TEXTUAL-CONVENTION values managed by 
IANA are in the range 0 to 255, inclusive. Each value uniquely 
identifies a standards-track Message Processing Model of the Message 
Processing Subsystem within a SNMP Management Architecture. 


Should this range prove insufficient in the future, an enterprise 
number may be obtained for the standards committee to get an 
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additional 256 possible values. 


As of this writing, there are several values of 


messageProcessingModel defined for use with SNMP. They are as 
follows: 

O reserved for SNMPv1 

1 reserved for SNMPv2c 

2 reserved for SNMPv2u and SNMPv2* 

3 reserved for SNMPv3 


6.3. SnmpEngineID Formats 


The SnmpEngineID TEXTUAL-CONVENTION’s fifth octet contains a format 
identifier. The values managed by IANA are in the range 6 to 127, 
inclusive. Each value uniquely identifies a standards-track 
SnmpEngineID format. 


7. Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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9. Security Considerations 


This document describes how an implementation can include a Security 
Model to protect management messages and an Access Control Model to 
control access to management information. 


The level of security provided is determined by the specific Security 
Model implementation(s) and the specific Access Control Model 
implementation(s) used. 


Applications have access to data which is not secured. Applications 
SHOULD take reasonable steps to protect the data from disclosure. 


It is the responsibility of the purchaser of an implementation to 
ensure that: 


1) an implementation complies with the rules defined by this 
architecture, 


2) the Security and Access Control Models utilized satisfy the 
security and access control needs of the organization, 


3) the implementations of the Models and Applications comply with 
the model and application specifications, 


4) and the implementation protects configuration secrets from 
inadvertent disclosure. 


This document also contains a MIB definition module. None of the 


objects defined is writable, and the information they represent is 
not deemed to be particularly sensitive. However, if they are deemed 
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sensitive in a particular environment, access to them should be 
restricted through the use of appropriately configured Security and 
Access Control models. 


10. References 


[RFC1155] 


[RFC1157] 


[RFC1212] 


[RFC1901] 


[RFC2578] 


[RFC2579] 


[RFC2580] 


[RFC1905] 


[RFC1906] 


[RFC1907] 


Rose, M. and K. McCloghrie, "Structure and 
Identification of Management Information for TCP/IP- 
based internets", STD 16, RFC 1155, May 1990. 


Case, J., M. Fedor, M. Schoffstall and J. Davin, "The 
Simple Network Management Protocol", STD 15, RFC 1157, 
May 1990. 


Rose, M. and K. McCloghrie, "Concise MIB Definitions", 
STD 16, RFC 1212, March 1991. 


The SNMPv2 Working Group, Case, J., McCloghrie, K., 
Rose, M. and S. Waldbusser, "Introduction to 
Community-based SNMPv2", RFC 1901, January 1996. 


McCloghrie, K., Perkins, D. and J. Schoenwaelder, 
"Structure of Management Information Version 2 (SMIv2)", 
STD 58, RFC 2578, April 1999. 


McCloghrie, K., Perkins, D. and J. Schoenwaelder,, 
"Textual Conventions for SMIv2", STD 58, RFC 2579, April 
1999. 


McCloghrie, K., Perkins, D. and J. Schoenwaelder, 
"Conformance Statements for SMIv2", STD 58, RFC 2580, 
April 1999. 


The SNMPv2 Working Group, Case, J., McCloghrie, K., 
Rose, M. and S. Waldbusser, "Protocol Operations for 
Version 2 of the Simple Network Management Protocol 
(SNMPv2)", RFC 1905, January 1996. 


The SNMPv2 Working Group, Case, J., McCloghrie, K., 
Rose, M. and S. Waldbusser, "Transport Mappings for 
Version 2 of the Simple Network Management Protocol 
(SNMPv2)", RFC 1906, January 1996. 


The SNMPv2 Working Group, Case, J., McCloghrie, K., 
Rose, M. and S. Waldbusser, "Management Information Base 
for Version 2 of the Simple Network Management Protocol 
(SNMPv2)", RFC 1907 January 1996. 


SNMPv3 Working Group Standards Track [Page 52] 


RFC 2571 


[RFC1908] 


[RFC1909] 


[RFC1910] 


[RFC2279] 


[RFC2119] 


[BCP-11] 


[RFC2233] 


[RFC2572] 


[RFC2574] 


[RFC2575] 


[RFC2573] 


[RFC2570] 


[SNMP -COEX] 


Architecture for SNMP Frameworks April 1999 


The SNMPv2 Working Group, Case, J., McCloghrie, K., 
Rose, M. and S. Waldbusser, "Coexistence between Version 
1 and Version 2 of the SNMP-standard Network Management 
Framework", RFC 1908, January 1996. 


McCloghrie, K., Editor, "An Administrative 
Infrastructure for SNMPv2", RFC 1909, February 1996. 


Waters, G., Editor, "User-based Security Model for 
SNMPv2", RFC 1910, February 1996. 


Yergeau, F., "UTF-8, a transformation format of ISO 
10646", RFC 2279, January, 1998. 


Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 


Hovey, R. and S. Bradner, "The Organizations Involved in 
the IETF Standards Process", BCP 11, RFC 2028, October 
1996. 


McCloghrie, K. and F. Kastenholz. "The Interfaces Group 
MIB using SMIv2", RFC 2233, November 1997. 


Case, J., Harrington, D., Presuhn, R. and B. Wijnen, 
"Message Processing and Dispatching for the Simple 
Network Management Protocol (SNMP)", RFC 2572, April 
1999. 


Blumenthal, U. and B. Wijnen, "The User-Based Security 
Model for Version 3 of the Simple Network Management 
Protocol (SNMPv3)", RFC 2574, April 1999. 


Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 
Access Control Model for the Simple Network Management 
Protocol (SNMP)", RFC 2575, April 1999. 


Levi, D. B., Meyer, P. and B. Stewart, "SNMP 
Applications", RFC 2573, April 1999. 


Case, J., Mundy, R., Partain, D. and B. Stewart, 
"Introduction to Version 3 of the Internet-standard 
Network Management Framework", RFC 2570, April 1999. 


Frye, R., Levi, D. and B. Wijnen, "Coexistence between 
Version 1, Version 2, and Version 3 of the Internet- 
standard Network Management Framework", Work in 
Progress. 


SNMPv3 Working Group Standards Track [Page 53] 


RFC 2571 Architecture for SNMP Frameworks 


11. 


Editor’s Addresses 


Bert Wijnen 

IBM T.J. Watson Research 
Schagen 33 

3461 GL Linschoten 
Netherlands 


Phone: +31 348-432-794 
EMail: wijnen@vnet.ibm.com 


Dave Harrington 
Cabletron Systems, Inc 
Post Office Box 5005 
Mail Stop: Durham 

35 Industrial Way 
Rochester, NH 03867-5005 


USA 
Phone: +1 603-337-7357 
EMail: dbh@ctron.com 


Randy Presuhn 

BMC Software, Inc. 
965 Stewart Drive 
Sunnyvale, CA 94086 


USA 

Phone: +1 408-616-3100 

Fax: +1 408-616-3101 
EMail: randy_presuhn@bmc.com 


SNMPv3 Working Group Standards Track 


April 1999 


[Page 54] 


RFC 2571 Architecture for SNMP Frameworks April 1999 


APPENDIX A 


A. 


Guidelines for Model Designers 


This appendix describes guidelines for designers of models which are 
expected to fit into the architecture defined in this document. 


SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to 
provide trivial authentication and access control. SNMPvl and SNMPv2c 
Frameworks can coexist with Frameworks designed according to this 
architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks 
could be designed to meet the requirements of this architecture, but 
this document does not provide guidelines for that coexistence. 


Within any subsystem model, there should be no reference to any 
specific model of another subsystem, or to data defined by a specific 
model of another subsystem. 


Transfer of data between the subsystems is deliberately described as 
a fixed set of abstract data elements and primitive functions which 
can be overloaded to satisfy the needs of multiple model definitions. 


Documents which define models to be used within this architecture 
SHOULD use the standard primitives between subsystems, possibly 
defining specific mechanisms for converting the abstract data 
elements into model-usable formats. This constraint exists to allow 
subsystem and model documents to be written recognizing common 
borders of the subsystem and model. Vendors are not constrained to 
recognize these borders in their implementations. 


The architecture defines certain standard services to be provided 
between subsystems, and the architecture defines abstract service 
interfaces to request these services. 


Each model definition for a subsystem SHOULD support the standard 
service interfaces, but whether, or how, or how well, it performs the 
service is dependent on the model definition. 


.1. Security Model Design Requirements 


.1.1. Threats 


A document describing a Security Model MUST describe how the model 
protects against the threats described under "Security Requirements 
of this Architecture", section 1.4. 
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A.1.2. Security Processing 


Received messages MUST be validated by a Model of the Security 
Subsystem. Validation includes authentication and privacy processing 
if needed, but it is explicitly allowed to send messages which do not 
require authentication or privacy. 


A received message contains a specified securityLevel to be used 
during processing. All messages requiring privacy MUST also require 
authentication. 


A Security Model specifies rules by which authentication and privacy 
are to be done. A model may define mechanisms to provide additional 
security features, but the model definition is constrained to using 
(possibly a subset of) the abstract data elements defined in this 
document for transferring data between subsystems. 


Each Security Model may allow multiple security protocols to be used 
concurrently within an implementation of the model. Each Security 
Model defines how to determine which protocol to use, given the 
securityLevel and the security parameters relevant to the message. 
Each Security Model, with its associated protocol(s) defines how the 
sending/receiving entities are identified, and how secrets are 
configured. 


Authentication and Privacy protocols supported by Security Models are 
uniquely identified using Object Identifiers. IETF standard protocols 
for authentication or privacy should have an identifier defined 
within the snmpAuthProtocols or the snmpPrivProtocols subtrees. 
Enterprise specific protocol identifiers should be defined within the 
enterprise subtree. 


For privacy, the Security Model defines what portion of the message 
is encrypted. 


The persistent data used for security should be SNMP-manageable, but 
the Security Model defines whether an instantiation of the MIB is a 
conformance requirement. 


Security Models are replaceable within the Security Subsystem. 
Multiple Security Model implementations may exist concurrently within 
an SNMP engine. The number of Security Models defined by the SNMP 
community should remain small to promote interoperability. 


A.1.3. Validate the security-stamp in a received message 


A Message Processing Model requests that a Security Model: 
- verifies that the message has not been altered, 
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- authenticates the identification of the principal for whom the 
message was generated. 
- decrypts the message if it was encrypted. 


Additional requirements may be defined by the model, and additional 
services may be provided by the model, but the model is constrained 
to use the following primitives for transferring data between 
subsystems. Implementations are not so constrained. 


A Message Processing Model uses the processIncomingMsg primitive as 
described in section 4.4.2. 


A.1.4. Security MIBs 


Each Security Model defines the MIB module(s) required for security 
processing, including any MIB module(s) required for the security 
protocol(s) supported. The MIB module(s) SHOULD be defined 
concurrently with the procedures which use the MIB module(s). The 
MIB module(s) are subject to normal access control rules. 


The mapping between the model-dependent security ID and the 
securityName MUST be able to be determined using SNMP, if the model- 
dependent MIB is instantiated and if access control policy allows 
access. 


A.1.5. Cached Security Data 


For each message received, the Security Model caches the state 
information such that a Response message can be generated using the 
same security information, even if the Local Configuration Datastore 
is altered between the time of the incoming request and the outgoing 
response. 


A Message Processing Model has the responsibility for explicitly 
releasing the cached data if such data is no longer needed. To enable 
this, an abstract securityStateReference data element is passed from 
the Security Model to the Message Processing Model. 


The cached security data may be implicitly released via the 
generation of a response, or explicitly released by using the 
stateRelease primitive, as described in section 4.5.1. 


A.2. Message Processing Model Design Requirements 


An SNMP engine contains a Message Processing Subsystem which may 
contain multiple Message Processing Models. 
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The Message Processing Model MUST always (conceptually) pass the 
complete PDU, i.e., it never forwards less than the complete list of 
varBinds. 


A.2.1. Receiving an SNMP Message from the Network 


Upon receipt of a message from the network, the Dispatcher in the 
SNMP engine determines the version of the SNMP message and interacts 
with the corresponding Message Processing Model to determine the 
abstract data elements. 


A Message Processing Model specifies the SNMP Message format it 
supports and describes how to determine the values of the abstract 
data elements (like msgID, msgMaxSize, msgFlags, 
msgSecurityParameters, securityModel, securityLevel etc). A Message 
Processing Model interacts with a Security Model to provide security 
processing for the message using the processIncomingMsg primitive, as 
described in section 4.4.2. 


A.2.2. Sending an SNMP Message to the Network 


The Dispatcher in the SNMP engine interacts with a Message Processing 
Model to prepare an outgoing message. For that it uses the following 
primitives: 


- for requests and notifications: prepareOutgoingMessage, as 
described in section 4.2.1. 


- for response messages: prepareResponseMessage, as described in 
section 4.2.2. 


A Message Processing Model, when preparing an Outgoing SNMP Message, 
interacts with a Security Model to secure the message. For that it 
uses the following primitives: 


- for requests and notifications: generateRequestMsg, as 
described in section 4.4.1. 


- for response messages: generateResponseMsg as described in 
section 4.4.3. 


Once the SNMP message is prepared by a Message Processing Model, 


the Dispatcher sends the message to the desired address using the 
appropriate transport. 
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A.3. Application Design Requirements 


Within an application, there may be an explicit binding to a specific 
SNMP message version, i.e., a specific Message Processing Model, and 

to a specific Access Control Model, but there should be no reference 

to any data defined by a specific Message Processing Model or Access 

Control Model. 


Within an application, there should be no reference to any specific 
Security Model, or any data defined by a specific Security Model. 


An application determines whether explicit or implicit access control 
should be applied to the operation, and, if access control is needed, 


which Access Control Model should be used. 


An application has the responsibility to define any MIB module(s) 
used to provide application-specific services. 


Applications interact with the SNMP engine to initiate messages, 
receive responses, receive asynchronous messages, and send responses. 


A.3.1. Applications that Initiate Messages 


Applications may request that the SNMP engine send messages 
containing SNMP commands or notifications using the sendPdu primitive 
as described in section 4.1.1. 


If it is desired that a message be sent to multiple targets, it is 
the responsibility of the application to provide the iteration. 


The SNMP engine assumes necessary access control has been applied to 
the PDU, and provides no access control services. 


The SNMP engine looks at the "expectResponse" parameter, and if a 
response is expected, then the appropriate information is cached such 
that a later response can be associated to this message, and can then 
be returned to the application. A sendPduHandle is returned to the 
application so it can later correspond the response with this message 
as well. 


A.3.2. Applications that Receive Responses 
The SNMP engine matches the incoming response messages to outstanding 
messages sent by this SNMP engine, and forwards the response to the 


associated application using the processResponsePdu primitive, as 
described in section 4.1.4. 
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A.3.3. Applications that Receive Asynchronous Messages 


When an SNMP engine receives a message that is not the response to a 
request from this SNMP engine, it must determine to which application 
the message should be given. 


An Application that wishes to receive asynchronous messages registers 
itself with the engine using the primitive registerContextEnginelD as 
described in section 4.1.5. 


An Application that wishes to stop receiving asynchronous messages 
should unregister itself with the SNMP engine using the primitive 
unregisterContextEngineID as described in section 4.1.5. 


Only one registration per combination of PDU type and contextEnginelD 
is permitted at the same time. Duplicate registrations are ignored. 
An errorIndication will be returned to the application that attempts 
to duplicate a registration. 


All asynchronously received messages containing a registered 
combination of PDU type and contextEngineID are sent to the 
application which registered to support that combination. 


The engine forwards the PDU to the registered application, using the 
processPdu primitive, as described in section 4.1.2. 


A.3.4. Applications that Send Responses 


Request operations require responses. An application sends a 
response via the returnResponsePdu primitive, as described in section 
AL. 


The contextEngineID, contextName, securityModel, securityName, 
securitylevel, and stateReference parameters are from the initial 
processPdu primitive. The PDU and statusInformation are the results 
of processing. 


A.4. Access Control Model Design Requirements 


An Access Control Model determines whether the specified securityName 
is allowed to perform the requested operation on a specified managed 

object. The Access Control Model specifies the rules by which access 

control is determined. 


The persistent data used for access control should be manageable 


using SNMP, but the Access Control Model defines whether an 
instantiation of the MIB is a conformance requirement. 
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The Access Control Model must provide the primitive isAccessAllowed. 
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B. Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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